Handle nullable drag entries in desktop_drop web to avoid zip-drag crashes - #459

Refs #1831

## What

Drag-and-drop upload was broken on web: the drop area highlighted,
releasing never uploaded, and the highlight stayed stuck until a page
refresh. The reporter hit it dragging from the browser's downloads menu.

`desktop_drop`'s web handler calls `webkitGetAsEntry()!` on every item
in the drag. That returns null for `kind == 'string'` items, and a drag
routinely carries them alongside its files — the downloads menu sends
`text/uri-list` and `text/plain` next to the file. The null assert
throws synchronously inside `List.generate`, before the `.catchError`
further down the chain is attached, so `performOperation_web` is never
invoked. No `DropDoneEvent` reaches the app, the file never uploads, and
`DropTarget`'s status never resets — hence the stuck highlight. The file
was in the drag the whole time.

This points `desktop_drop` at our fork, which null-guards the entry and
falls back to `getAsFile()`. `getAsFile()` and `webkitGetAsEntry()` are
not equivalent — the latter needs a filesystem-backed entry and returns
null for exactly the items the former handles. That is also why the same
drag works on other web upload targets and not on ours.

## Changes

- `pubspec.yaml`: `dependency_overrides` pointing `desktop_drop` at
`autobutler-org/flutter-plugins` `main`, with a comment explaining why
and when to remove it
- `pubspec.lock`: resolved to `29e5924`

Fork commit:
[autobutler-org/flutter-plugins@29e5924](autobutler-org/flutter-plugins@29e5924)

Upstream PR:
[MixinNetwork/flutter-plugins#503](MixinNetwork/flutter-plugins#503).
The root cause is already filed upstream as
[#456](MixinNetwork/flutter-plugins#456) from
a different trigger (dragging out of a zip viewer, likewise no
`FileSystemEntry`); the downloads-menu case is new evidence on the same
defect. A stalled draft,
[#459](MixinNetwork/flutter-plugins#459), fixes
the null assert the same way — our version additionally notifies with
the resulting list even when it is empty, so a drag carrying no files at
all (a dragged link, selected text) clears the drop target instead of
wedging it the same way.

## PR Type

- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Docs / content
- [ ] Chore / tooling
- [ ] Tests

## Surface

- [ ] Backend (Go)
- [x] Frontend (Flutter)
- [ ] API / swagger
- [ ] CI / workflows
- [ ] Docs / content only

## Testing

- [x] Local testing recommended (UI changes, routing, behavior changes)
- [ ] Local testing not needed (logic-only, docs, trivial change)
- [ ] Includes new automated tests
- [x] Manually tested by author

Tested side by side on macOS: stock 0.8.4 on one port reproduces the
failure, the patched build on another uploads normally. The served
bundles were checked to confirm the difference was really the patch —
`getAsFile` appears in the compiled output of the patched build and is
absent from stock 0.8.4. `make check` passes.

## Bot Review Guidance

The risk here is the dependency override, not application code. Worth
checking that tracking a fork's `main` is acceptable, and that
`pubspec.lock` pinning the resolved commit is considered sufficient for
reproducibility.

## Notes

**Deliberately `Refs`, not `Closes`.** This fixes the crash but not the
whole issue. Three independent defects found during the investigation
are untouched and #1831 should stay open for them:

- 90 ms folder-hover debounce race (`file_browser_page.dart:763-787`,
`:2199`) — a drop released between the page target and a folder target
lands in neither; separately, after hovering any folder row the
page-level highlight is dead for the rest of that drag
- `FolderDropTarget` has no `enable` gate (`folder_drop_target.dart:35`)
while the page target gates on `!_isUploading` (`:2171`), so folder rows
highlight during a background upload and then early-return
- `_isWebDragging` has no reset path other than an exit/done event — no
timeout, no reset on rebuild

**No automated coverage.** There are no widget tests for
`FolderDropTarget`, `FolderDropWrapper`, or the page's drag state
machine; the only existing test is pure-function coverage of
`flattenDroppedItems`. Every defect above lives in the untested wiring.

**Cleanup owed.** The override tracks a moving ref. `pubspec.lock` pins
the resolved commit so builds stay reproducible, but `pub upgrade` will
follow wherever that branch goes. Remove the override once a
`desktop_drop` release carrying the fix reaches pub.dev — the comment in
`pubspec.yaml` is the only thing carrying that reminder.

Signed-off-by: James Orson <jamesaorson@gmail.com>